home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jul 89 / W0105-Inappropriate use o-Jul89 < prev    next >
Encoding:
Text File  |  1989-08-22  |  2.2 KB  |  44 lines  |  [TEXT/GEOL]
  1. Item    7409264                         21-July-89        14:17
  2.  
  3. From:   D2605                           Xanadu Operating,Marc Stiegler, PRT
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. cc:     FRIEDRICH1                      Friedrich, Steve
  8.         BURBECK.S                       Burbeck, Steve
  9.         MACAPP.TEST                     MacApp SQA Team
  10.  
  11. Sub:    Inappropriate use of FailNIL
  12.  
  13. MacApper's
  14.     I recently found a (very) minor bug, but one that got me to thinking a bit
  15. about how errors are handled during development (vs released application).  The
  16. bug was that I had managed to build a bad version of my application that didn't
  17. contain cmnu resources 128 or 129.  When I ran it, MacApp alerted me that the
  18. application ran out of memory.
  19.     After spending a while (hour-ish) tracking this down, I noticed that the
  20. initialization code was using FailNIL after getResource to decide if it could
  21. continue.  In this case, since the resources were missing, it failed, reporting
  22. lack of memory.
  23.     I have also used the FailNIL trick (in place of ASSERTs), so it surely IS
  24. useful.  It is not quite the same as an ASSERT, however, because the test
  25. should remain in the production code.  Assertion doesn't do anything if qDebug
  26. is false, so it's not a reasonable replacement in this case.
  27.     I think the appropriate thing to do is to add a
  28. FailNILError( ptr: UNIV PTR; msg: LONGINT );
  29.     routine, and replace FailNIL's that are being used as asserts.  The msg
  30. would be used to present an appropriate error (like for not finding a resource
  31. use "Internal Program Error: Resource not found") rather than out of memory. A
  32. few "standard" errors (such as the one above) could be provided.  It would make
  33. it bit easier to debug during development, and would also produce a more
  34. correct message in a release application, allowing a tech support person a
  35. better chance of deciding what's wrong.   (I can just see some inexperienced
  36. people ResEdit'ing applications and accidently deleting resources...)
  37.     I've added the routine to my library, but I think it's useful in general,
  38. and if added, should be used in those places FailNIL is now (inappropriately)
  39. used.
  40.     comments?
  41. --Hugh Hoover
  42.   Xanadu Operating Company
  43.  
  44.